This specification relates to monitoring behavior with respect to a software program, such as a media player application.
The Internet is widely used to distribute multimedia information, including video and audio data. Such information can be downloaded as a file, or streamed to a client computer, where a media player or real-time communications application can process and output the media content to a display device and one or more speakers. The media player or real-time communications application can be a program written for a particular operating system (OS) on a computer platform. Alternatively, the media player or real-time communications application can be platform-independent software that runs inside another program, such as a runtime environment, on a computer platform. For example, a FLASH® multimedia player program can play streamable content by running in a FLASH® runtime or an AIR® runtime environment provided by Adobe Systems Incorporated of San Jose, Calif., and using the runtime to render the media content to appropriate output devices. Moreover, the runtime environment can itself be a plug-in to another program, such as a Web browser program.
In addition, media content can include associated metadata that provides information about the content to be rendered. Examples of metadata include author, publication and licensing information. Moreover, metadata can also include references to pre-exiting functions implemented in the media player itself that perform certain actions, such as recording information about media viewing patterns, showing an advertisement to a current viewer of the media content being rendered, or sending information to another computer accessible over the Internet for aggregation and analysis of media viewing statistics.
The media player can run inside a runtime environment, or an application execution environment, which is a virtualization environment that works in conjunction with the native services (e.g., an operating system) of a computing device to provide a consistent well-defined environment in which applications can be loaded and executed. An application execution environment typically includes facilities such as memory management (e.g., garbage collection), standard libraries, media decoders, user interface frameworks and input-output interfaces. An application designed to run within an application execution environment can often be developed rapidly because developers can rely on the consistency of the application execution environment—even if the environment itself exists on widely varying systems. Security features within the runtime environment can provide built-in safety mechanisms to ensure that applications do not pose a threat to the platform upon which they are executed. For example, an application may require a security check to access a remote network or certain local resources.
An application execution environment can load an application from an encoded representation of the application. For example, the encoded representation can have a pre-defined syntactic structure such as a programming language (e.g., source code) or can include well-defined virtual instructions (e.g., platform-independent bytecode, such as Macromedia Flash® bytecode). To load applications, the application execution environment decodes the encoded representation of the application into instructions and executes the instructions of the application. Application execution environments are sometimes referred to as interpreters or virtual machines.
When the loaded application is executed, the application execution environment controls the resources that the application is allowed to access. For example, if an application is downloaded from the Internet, the application may be allowed to display information and receive user input, but may not be allowed to access an attached storage device. An application can be classified such that the application's classification identifies a particular security context within the execution environment with which the application is loaded. An application that has a different classification is loaded into a different security context. An application loaded using one security context is prevented from accessing, modifying or interfering with an application loaded using a different security context. For example, the source Internet domain (e.g., “some-made-up-company.com”) for each application can be used to classify the application into a corresponding security context, thereby isolating applications from different source domains. However, it is often desirable for an author of an application to reuse functionality of one application within another application, even if the two applications do not share the same classification.
Some application execution environments allow applications to explicitly establish inter-isolation-environment communication channels. Typically one or both of the applications must be explicitly designed to exchange data through an established channel. For example, when a SWF application is loaded into the FLASH® runtime, it is placed into its natural security context corresponding to the Uniform Resource Locator (URL). SWF is a file format, such as the SWF File Format Specification (Version 10) as published (see adobe.com/devnet/swf/pdf/swf_file_format_spec_v10.pdf) by Adobe Systems Incorporated of San Jose, Calif. An object of this application may load another SWF application from any allowed source, and the loaded SWF can be placed in either its own natural security context or the loader's security context. If the loader and loaded SWF applications are in different security domains, they must give explicit permission to access each other's data. Thus, in the context of program monitoring (e.g., monitoring performance and/or usage) the main SWF application explicitly loads the monitoring SWF application and gives permission to access certain information. The main SWF application may also have to pass certain parameters explicitly to the monitoring object to support the monitoring process.